ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group97b.txt/000139_icon-group-sender _Mon Dec 15 08:30:35 1997.msg

Internet Message Format | 2000-09-20 | 9KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id IAA06791
    for <[e-mail]>; Mon, 15 Dec 1997 08:30:30 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA01610; Mon, 15 Dec 1997 08:30:31 -0700
From: [e-mail]
Date: Fri, 12 Dec 1997 23:57:18 -0600
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Subject: Extensions to `open'
To: [e-mail]
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: [e-mail]
Status: RO

>I would like to propose a small but very useful extension to Icon: that
it should be possible to open a directory by specifying a "d" option to
the `open' function.

Personally, I wrote (some years ago) a loadable function DIRFNC (in assembler)
for SNOBOL4+ which offers similar getfirst/getnext features.  Despite having my
OWN function, I probably actually use the "shell out to DIR" technique more when
writing real programs.  Why?

1)  it's always available, even if I haven't brought my function along to the
client site where I am

2)  it's nearly as easy to use

>It seems that any extension to Icon ought to satisfy three criteria:
  (1) It provides functionality that isn't easily achieved by other means.

And that's part of the problem... this functionality is in fact pretty easy to
achieve... if not in mainline code, then certainly in a small library
subroutine.

>  (2) It is stylistically consistent with the rest of the language and
won't break existing code,.

That shouldn't be a problem.

>  (3) For a minor extension, it should take someone familiar with the
implementation no more than half a day to code.  (Testing and debugging,
of course, has to be added on.)

Writing such a library routine probably comes close to that.

>Icon already recognizes the existence of directories by providing the
"chdir" function.  At first glance it would seem that being able to scan
a directory is easy enough with the `system' function: you just call the
system command for the purpose.

Right.

>But that approach has two difficulties.

>It's very awkward to retrieve the output, since `system' returns only an
exit code.

But you were GOING to call open and read it "as a file" anyhow, right?  So you
wouldn't retrieve the output via SYSTEM anyhow.  If SYSTEM redirects the output
to a file, you can then get basically what you want (yeah, okay, you have
multiuser issues to prevent walking on some other user's file... if that
situation applies to you... but in that case you probably have to handle the
same issue in mainline code and your other file accesses anyhow).

> More significantly, the user code depends unnecessarily on
the operating environment:

This is a rather minor issue really because most users simply in reality don't
have multiple environments that they have to run their programs in.  For
example, I'd be *perfectly* happy to just have an MS-DOS/Windows version, since
I wouldn't expect to ever need to run the program in a Mac or Unix environment.
 Probably the huge majority of all computer users are in the same situation.

> in Unix you use `ls', in DOS/Windows you use
`dir', and in MacOS you use something else again which I don't know.

Yes, but it's trivial under Unix to set up "dir" as an alias to "ls" and it's
nearly as easy under DOS/Windows to set up a batch file named "ls" which invokes
"dir".  Handling options is somewhat trickier, of course, but then again that
opens up a whole other can of worms which I'll get to in a moment.

> Yet directory structure is a concept common to all modern operating
systems.

Yes, but they don't all handle it in quite the same way.  For example, under
Windows 95 and NT you're allowed to have filenames which contain spaces.  You
also find that in European (and other) countries, time and date fields are
generally formatted differently than they are here in the USA.  Volume names and
drive specs (not to mention site/node/? and network addresses) are handled
differently.  Where Unix uses "/" to separate subdirectories, MS-DOS/Windows/NT
use "\".  Microsoft operating systems generally use "/" for options, while Unix
usually uses "-" to designate options.  The file attributes provided by
different systems are inconsistent:  Novell servers have an "execute permission"
for files which allows a program to be executed but not read.  Some systems'
directories contain "last accessed" date (in addition to creation or last
modification).  Some schemes have user-specific rights attached to individual
files.

> It ought to be possible to read a directory without having to
resort to system-dependent code.

Agreed that that would be nice, but in reality when you're accessing directory
entries, that often (admittedly, not ALWAYS) implies you doing something that
involves a more detailed understanding of how the system directories are
organized.

Just one other example:  since Intel operating systems don't support direct
aliases to filenames, you know that the directory (if undamaged, anyhow) is
properly tree-structured and cannot contain any loops or cross-pointere.  I
don't believe that this is guaranteed under Unix systems, (is it?)

> Adding an option letter to the second argument of `open' is clearly
consistent with Icon as it stands.  The associated file would then act
as a generator whose result sequence consists of the names of the files
in the directory.  `read' would produce the next file name in the
directory; `reads' should probably produce an error when called on a
directory (as it does, I believe, when called on an output file).

>As to the work involved: although I don't know the actual code, I assume
that it involves going to the place where the option letters are
extracted for `open' and inserting one additional case, together with the
appropriate system call.

>It also involves recording the fact that the
file is a directory.  In the code for `read', it involves substituting
the "get next filename" API for the "read line" API; both Unix and DOS
provide such an API.

Right, but presumably the information available from each will not be formatted
in the same fashion once retrieved and returned... so much for cross-platform
common code!

So you have to in fact change not only open and read, but essentially the entire
I/O package (close, seek, etc too).  How do you handle directory opens for
OUTPUT?  How are errors reported?  Are file-type fault returned conditions
really appropriate for directories, or do you need other kinds?

The other issue is that if you're going to provide such a "read directory as a
file" feature, you really would WANT it to be consistent not just for one
language, but on a system-wide basis.  And that sounds like in a perfect world
it would be more desirable to implement it (under MS-DOS-type systems anyhow?)
as a small TSR which would intercept opens/reads/closes/etc at the MS-DOS level
(rather that at the language runtime library level) and then you could directly
use other system commands on directories too...
FIND/MORE/SORT/LIST/TYPE/PRINT/etc, and the same features that work then under
Icon would work (and the same way) under BASIC, COBOL, FORTRAN, Assembler, or
other languages too.

>Then there's another extension, perhaps even more useful but not quite
as straightforward to implement: if `open' is called with a null
argument, it invokes the current system's API for *dynamically*
selecting a file to be opened.  This is the usual dialog that enables a
user to browse the directory structure, looking for the file to be
opened.

Agreed that this is a nice extension, although again that implies that you can
use the screen (and put it back the way it was when you're done).  And
implementing that is substantially different under (say) MS-DOS than it is under
(say) Windows95.

> I have a hunch that if graphical user interfaces were common in
the days when Ralph was first designing Icon, he would have included
this facility.  It recognizes that programs are now used in far more
interactive environments than they were in the old days.

Agreed.

But I still think that writing such routines in the classic way is at least
(most of the time) pretty easy (the interactive one less so, but then again you
probably only need to do it once).

Gordon Peterson
http://www.computek.net/public/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/